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Abstract 


This specification describes an extension to the Optimized Link State 
Routing Protocol version 2 (OLSRv2) to support multiple routing 
topologies, while retaining interoperability with OLSRv2 routers that 
do not implement this extension. 


This specification updates RFCs 7188 and 7631 by modifying and 
extending TLV registries and descriptions. 


Status of This Memo 
This document is not an Internet Standards Track specification; it is 
published for examination, experimental implementation, and 


evaluation. 


This document defines an Experimental Protocol for the Internet 


community. This document is a product of the Internet Engineering 
Task Force (IETF). It represents the consensus of the IETF 

community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Not 


all documents approved by the IESG are a candidate for any level of 
Internet Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7722. 
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1. Introduction 


The Optimized Link State Routing Protocol version 2 [RFC7181] 

(OLSRv2) is a proactive link state routing protocol designed for use 
in Mobile Ad Hoc Networks (MANETs) [RFC2501]. One of the significant 
improvements of OLSRv2 over its Experimental precursor [RFC3626] is 
the ability of OLSRv2 to use link metrics to select routes other than 
minimum hop routes. 


A limitation that remains in OLSRv2 is that it uses a single link 
metric type for all routes. However, in some MANETs it would be 
desirable to be able to route packets using more than one link metric 
type. This specification describes an extension to OLSRv2 that is 
designed to permit this, while maintaining maximal interoperability 
with OLSRv2 routers not implementing this extension. 


The purpose of OLSRv2 can be described as to create and maintain a 
Routing Set, which contains all the necessary information to populate 
an IP routing table. In a similar way, the role of this extension 
can be described as to create and maintain multiple Routing Sets, one 
for each link metric type supported by the router maintaining the 
sets. 


1.1. Motivation and Experimentation 


Multi-topology routing is a natural extension to a link state routing 
protocol, such as OSPF (see [RFC4915]). However multi-topology 
routing for OLSRv2 does not yet benefit from extensive operational, 
or even experimental, experience. This specification is published to 
facilitate collecting such experience, with the intent that once 
suitable experimental evidence has been collected, an OLSRv2 Multi- 
Topology Routing Extension will be proposed for advancement onto the 
Standards Track. 


Any experiments using this protocol extension are encouraged. 
Reports from such experiments planned with pre-specified objectives 
and scenarios (including link, position, and mobility information) 
are particularly encouraged. Results from such experiments, 
documenting the following, are of particular importance: 


o Operation in networks that contain both routers implementing this 
extension and routers implementing only [RFC7181]. In particular, 
are there any unexpected interactions that can break the network? 


o Operation in networks with dynamic topologies, both due to 
mobility and due to link metric changes for reasons other than 
mobility. 
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o Operation in realistic deployments, and details thereof, including 
how many concurrent topologies were required. 


o Behavior of Routing Sets, including measures of successful route 
establishment. 


In addition, reports from experiments covering the following are also 
of value: 


o Which link metric types were useful, and how the metrics to 
associate with a given link were established. 


o How packet types were associated with link metric types (whether 
using Diffserv or an alternative mechanism). 


o Any data link-layer issues, and any cross-layer issues, including 
whether and how Neighborhood Discovery Protocol (NHDP) link 
quality was used. 


o Transport- and higher-layer issues observed, if any. 


o Resource requirements observed from running the protocol, 
including processing, storage, and bandwidth. 


o Network performance, including packet delivery results. 
o Any other implementation issues. 


The first bullet in the list directly above applies to unextended 
OLSRv2 [RFC7181] as well as with this extension, and potentially to 
other MANET routing protocols. This specification also allows 
experimentation with link metric types that are not compromises for 
handling multiple traffic types. 


2. Terminology and Notation 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
[RFC2119]. 
This specification uses the terminology of [RFC5444], [RFC6130], and 
[RFC7181], which is to be interpreted as described in those 
specifications. 


Additionally, this specification uses the following terminology: 


Router - A MANET router that implements [RFC7181]. 
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MT-OLSRv2 - The protocol defined in this specification as an 
extension to OLSRv2 [RFC7181]. 


This specification introduces the notation map[A -> B] to represent 
an associative mapping. The domain of this mapping (A) is, in this 
specification, always a set of link metric types that the router 
supports: either IFACE_METRIC_TYPES or ROUTER_METRIC_TYPES, as 
defined in Section 5. The codomain of this mapping (B) is a set of 
all possible values of an appropriate type. In this specification, 
this type is always one of: 


o boolean (true or false), 
o willingness (a 4-bit unsigned integer from 0 to 15), 
o number of hops (an 8-bit unsigned integer from 0 to 255), or 


o link metric (either a representable link metric value, as 
described in [RFC7181], or UNKNOWN_METRIC). 


3. Applicability Statement 


The protocol described in this specification is applicable to a MANET 
for which OLSRv2 is otherwise applicable (see [RFC7181], Section 3), 
but in which multiple topologies are maintained, each characterized 
by a different choice of link metric type. It is assumed, but 
outside the scope of this specification, that the network layer is 
able to choose which topology to use for each packet, for example, 
using the Diffserv Code Point (DSCP) defined in [RFC2474]. This 
selection of topology MUST be consistent; that is, each router 
receiving a packet must make the same choice of link metric type, in 
order that each packet uses a single topology. This is necessary to 
avoid the possibility of a packet "looping" in the network. 


4. Protocol Overview and Functioning 


The purpose of this specification is to extend OLSRv2 [RFC7181] so as 
to enable a router to establish and maintain multiple routing 
topologies in a MANET, each topology associated with a link metric 
type. Routers in the MANET may each form part of some or all of 
these topologies, and each router will maintain a Routing Set for 
each topology that it forms part of, allowing separate routing of 
packets for each topology. 


MT-OLSRv2 is designed to interoperate with OLSRv2; a MANET can be 
created containing both routers that implement MT-OLSRv2 (MT-OLSRv2 
routers) and routers that do not implement MT-OLSRv2 and may be 
unaware of its existence (non-MT-OLSRv2 routers). MANETs may also be 
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created that are known to contain only MT-OLSRv2 routers. In both 
cases, but especially where a MANET contains both MT-OLSRv2 routers 
and non-MT-OLSRv2 routers, management may be required to ensure that 
the MANET will function as required, and will not, for example, 
unnecessarily fragment. (Such issues already arise in an 
OLSRv2-based MANET using multiple interfaces.) 


OLSRv2 is an extension of NHDP [RFC6130]. However, the extension in 
this specification does not modify NHDP, it only modifies Protocol 
Sets that are specific to OLSRv2, or elements in Protocol Tuples that 
were added by OLSRv2 and that are neither included in nor used by 
NHDP. In addition it does not use or modify the link quality 
mechanism in [RFC6130]. 


Each router implementing this specification selects a set of link 
metric types for each of its OLSRv2 interfaces. If all routers in 
the MANET implement MT-OLSRv2, then there are no restrictions within 
this specification on how these sets of link metrics are selected. 
(However, the issues described in the preceding paragraph still 
apply.) On the other hand, in MANETs containing non-MT-OLSRv2 
routers, the single link metric used by these non-MT-OLSRv2 routers 
must be included in the set of link metrics for each OLSRv2 interface 
of an MI-OLSRv2 router that may be heard on an OLSRv2 interface of a 
non-MT-OLSRv2 router in the MANET. 


Each router then determines an incoming link metric for each link 
metric type selected for each of its OLSRv2 interfaces. These link 
metrics are distributed using link metric TLVs contained in all HELLO 
messages sent on OLSRv2 interfaces and in all TC messages. Unless 
using only the single metric type used by non-MT-OLSRv2 routers, both 
HELLO and TC messages generated by an MT-OLSRv2 router include an 
MPR_TYPES Message TLV that indicates that this is an MT-OLSRv2 router 
and which metric types it supports (on the sending OLSRv2 interface 
for a HELLO message). 


An MT-OLSRv2 router maintains, for each supported neighbour metric 
type and for each symmetric 1-hop neighbor, the following: 


o link and neighbour metric values, 
o routing MPR status, 

o routing MPR selector status, and 
o advertised neighbour status. 


Each router may choose a different willingness to be a routing MPR 
for each link metric type that it supports. 
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A network using MT-OLSRv2 will usually require greater management 
than one using unmodified OLSRv2. In particular, the use of multiple 
metric types across the MANET must be managed, by administrative 
configuration or otherwise. As also for other decisions that may be 
made when using OLSRv2, a bad collective choice of metric type use 
will make the MANET anywhere from inefficient to nonfunctional, so 
care will be needed in selecting supported link metric types across 
the MANET. 


The meanings of link metric types are at the discretion of the MANET 
operator. They could be used, for example, to represent packets of 
different types, packets in streams of different rates, or packets 
with different trust requirements. Note that packets will generally 
not be delivered to routers that do not support that link metric 
type, and the MANET, and the packets sent in it, will need to be 
managed accordingly (especially if the MANET contains any 
non-MT-OLSRv2 routers). 


5. Parameters 


The parameters used in [RFC7181], and in its normative references, 
are used in this specification with the following changes. 


Each OLSRv2 interface will support a number of link metric types, 
corresponding to Type Extensions of the LINK_METRIC TLV defined in 
[RFC7181]. The router parameter LINK_METRIC_TYPE, used by routers 
that do not implement MT-OLSRv2, and used with that definition in 
this specification, is replaced in routers implementing MT-OLSRv2 by 
an interface parameter array IFACE_METRIC_TYPES and a router 
parameter array ROUTER_METRIC_TYPES. Each element in these arrays is 
a link metric type (i.e., a type extension used by the LINK_METRIC 
TLV [RFC7181]). 


The interface parameter array IFACE_METRIC_TYPES contains the link 
metric types supported on that OLSRv2 interface. The router 
parameter array ROUTER_METRIC_TYPES is the union of all of the 
IFACE_METRIC_TYPES. Both arrays MUST be without repetitions. 


If in a given deployment there might be routers that do not implement 
MT-OLSRv2, then IFACE_METRIC_TYPES MUST include LINK_METRIC_TYPE as 
its first element, so that the OLSRv2 interface can communicate with 
those routers. In that case, ROUTER_METRIC_TYPES MUST also include 
LINK_METRIC_TYPE as its first element. 


In addition, the router parameter WILL_ROUTING is extended to an 
array of values, one each for each link metric type in the router 
parameter list ROUTER_METRIC_TYPES. 
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6. Information Bases 


The Information Bases specified in [RFC7181], which extend those 
specified in [RFC6130], are further extended in this specification. 
With the exception of the Routing Set, the extensions in this 
specification are the replacement of single values (boolean, 
willingness, number of hops, or link metric) from [RFC7181] with 
elements representing multiple values (associative mappings from a 
set of metric types to their corresponding values). The following 
subsections detail these extensions. 


Note that, as in [RFC7181], an implementation is free to organize its 
internal data in any manner it chooses; it needs only to behave as if 
it were organized as described in [RFC7181] and this specification. 


6.1. Local Attached Network Set 


Each element AL_dist becomes a map[ROUTER_METRIC_TYPES -> number of 
hops]. 


Each element AL _metric becomes a map[ROUTER_METRIC_TYPES -> link 
metric]. 


6.2. Link Sets 


Each element L_in_metric becomes a map[IFACE_METRIC_TYPES -> link 
metric]. 


Each element L_out_metric becomes a map[IFACE_METRIC_TYPES -> link 
metric]. 


The elements of L_in_metric MUST be set following the same rules that 
apply to the setting of the single element L_in_metric in [RFC7181]. 


6.3. 2-Hop Sets 


Each element N2_in_metric becomes a map[ROUTER_METRIC_TYPES -> link 
metric]. 


Each element N2_out_metric becomes a map[ROUTER_METRIC_TYPES -> link 
metric]. 


6.4. Neighbor Set 


Each element N_in_metric becomes a map[ROUTER_METRIC_TYPES -> link 
metric]. 
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Each element N_out_metric becomes a map[ROUTER_METRIC_TYPES -> link 
metric]. 


Each element N_will_routing becomes a map[ROUTER_METRIC_TYPES -> 
willingness]. 


Each element N_routing_mpr becomes a map[ROUTER_METRIC_TYPES -> 
boolean]. 


Each element N_mpr_selector becomes a map[ROUTER_METRIC_TYPES -> 
boolean]. 


Each element N_advertised becomes a map[ROUTER_METRIC_TYPES -> 
boolean]. 


6.5. Router Topology Set 


Each element TR_metric becomes a map[ROUTER_METRIC_TYPES -> link 
metric]. 


Note that some values of TR_metric may now take the value 
UNKNOWN_METRIC. When used to construct a Routing Set, where just the 
corresponding link metric value from this mapping is used, Router 
Topology Tuples whose corresponding value from TR_metric is 
UNKNOWN_METRIC are ignored. 


6.6. Routable Address Topology Set 


Each element TA_metric becomes a map[ROUTER_METRIC_TYPES -> link 
metric]. 


Note that some values of TA_metric may now take the value 
UNKNOWN_METRIC. When used to construct a Routing Set, where just the 
corresponding link metric value from this mapping is used, Routable 
Address Topology Tuples whose corresponding value from TA_metric is 
UNKNOWN_METRIC are ignored. 


6.7. Attached Network Set 


Each element AN_dist becomes a map[ROUTER_METRIC_TYPES -> number of 
hops]. 


Each element AN_metric becomes a map[ROUTER_METRIC_TYPES -> link 
metric]. 


Note that some values of AN_metric may now take the value 
UNKNOWN_METRIC. When used to construct a Routing Set, where just the 
corresponding link metric value from this mapping is used, Attached 
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UNKNOWN_METRIC are ignored. 

6.8. Routing Sets 


There is a separate Routing Set for each link metric type in 
ROUTER_METRIC_TYPES. 


7. TLVs 


This specification makes the following additions and extensions to 
the TLVs defined in [RFC7181]. 


7.1. Message TLVs 


One new Message TLV is defined in this specification, and one 
existing Message TLV is extended by this specification. 


7.1.1. MPR_TYPES TLV 


The MPR_TYPES TLV is used in both HELLO messages sent over OLSRv2 
interfaces and TC messages. A message MUST NOT contain more than one 
MPR_TYPES TLV. 


The presence of this TLV in a message is used to indicate that the 
router supports MT-OLSRv2, in the same way that the presence of the 
MPR_WILLING TLV is used to indicate that the router supports OLSRv2, 


as specified in [RFC7181]. For this reason, the MPR_TYPES TLV has 
been defined with the same Type as the MPR_WILLING TLV, but with Type 
Extension = 1. 


This TLV may take a Value field of any size. Each octet in its Value 
field will contain a link metric type that is supported, either on 
any OLSRv2 interface, when included in a TC message, or on the OLSRv2 
interface on which a HELLO message including this TLV is sent. These 
octets MAY be in any order, but if there might be routers in the 
MANET that do not implement MT-OLSRv2, then the first octet MUST be 
LINK_METRIC_TYPE. 


7.1.2. MPR_WILLING TLV 


The MPR_WILLING TLV, which is used in HELLO messages, is specified in 
[RFC7181], and extended in this specification as enabled by 
[RFC7188]. 


The interpretation of this TLV, which is specified by [RFC7181] and 
uses all of its single-octet Value field, is unchanged. That 
interpretation uses bits 0-3 of its Value field to specify its 
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willingness to be a flooding TLV, and bits 4-7 of its Value field to 
be a routing TLV. Those latter bits are, when using this 
specification, interpreted as its willingness to be a routing TLV 
using the link metric type LINK_METRIC_TYPE. 


The extended use of this message TLV, as defined by this 
specification, defines additional 4-bit sub-fields of the Value 
field, starting with bits 4-7 of the first octet and continuing with 
bits 0-3 of the second octet, to represent willingness to be a 
routing MPR using the link metric types specified in this OLSRv2 
interface’s IFACE_METRIC_TYPES parameter, ordered as reported in the 
included MPR_TYPES Message TLV. Note that this means that, if there 
might be any non-MT-OLSRv2 routers, then the link metric type 
LINK_METRIC_TYPE will continue to occupy bits 4-7 of the first octet. 
(If there is no such TLV included, then the router does not support 
MT-OLSRv2, and only the first octet of the Value field will be used.) 


If the number of link metric types in this OLSRv2 interface’s 
IFACE_METRIC_TYPES parameter is even, then there will be an unused 
4-bit sub-field in bits 4-7 of the last octet of a full-sized Value 
field. These bits will not be used; they SHOULD all be cleared (’0’) 
on transmission and MUST be ignored on receipt. 


If the Value field in an MPR_WILLING TLV is shorter than its full 
length, then, as specified in [RFC7188], missing Value octets, i.e., 
missing willingness values, are considered as zero (WILL NEVER). 
This is the correct behavior. (In particular, it means that an 
OLSRv2 router that is not implementing MT-OLSRv2 will not act as a 
routing MPR for any link metric that it does not recognize.) 


7.2. Address Block TLVs 
New Type Extensions are defined for the LINK_METRIC TLV defined in 
[REC7181], and the Value fields of the MPR TLV and the GATEWAY TLV, 
both defined in [RFC7181], are extended, as enabled by [RFC7188]. 

E A EA LINK_METRIC TLV 


The LINK_METRIC TLV is used in HELLO messages and TC messages. This 
TLV is unchanged from the definition in [RFC7181]. 


Only a single Type Extension was specified by [RFC7181] -- 0 for 
"Link metric meaning as assigned by administrative action". This 
specification extends it to the range 0-7. This specification will 


work with any combination of Type Extensions both within and outside 
that range (assuming that the latter are defined as specified in 
[RFC7181]). 
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7.2.2. MPR TLV 


The MPR TLV is used in HELLO messages and indicates that an address 
with which it is associated is of a symmetric 1-hop neighbor that has 
been selected as an MPR. 


The Value field of this address block TLV is, in [RFC7181], defined 
to be one octet long, with the values 1, 2, and 3 defined. [RFC7188] 
redefines this Value field to be a bitfield where bit 7 (the least 
significant bit) denotes flooding status, bit 6 denotes routing MPR 
status, and bits 5-0 are unallocated (respecting the semantics of the 
bits/values 1, 2, and 3 from [RFC7181]). 


This specification, as enabled by [RFC7188], extends the MPR TLV to 
have a variable-length Value field. Bits are allocated in increasing 
significance within as many octets as are required. These bits 
specify, in order, that: 


o The neighbor with that network address has been selected as 
flooding MPR (1 bit). 


o The neighbor with that network address has been selected as 
routing MPR for each link metric type (1 bit each), in the same 
order as indicated in the Value field of an MPR_TYPES Message TLV. 


For interoperability with a router not implementing MT-OLSRv2, the 
two least significant bits of the first octet in the Value field of 
this TLV is as the TLV Value of an MPR TLV generated according to 
[RFC7181], as updated by [RFC7188]. 


7.2.3. GATEWAY TLV 


The GATEWAY TLV is used in TC messages to indicate that a network 
address is of an attached network. 


The Value field of this address block TLV is defined by [RFC7181] to 
be one octet long, containing the number of hops to that attached 
network. 


This specification, as enabled by [RFC7188], allows the extension of 
the GATEWAY TLV to have a variable-length Value field when the number 
of hops to each attached network is different for different link 
metric types. For interoperability with a router not implementing 
MT-OLSRv2, the first octet in the Value field of this TLV MUST be the 
TLV Value of the GATEWAY TLV generated according to [RFC7181]. 
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8. 


Te 


Any subsequent octets in the TLV Value field indicate the number of 
hops to the attached network for each other link metric type. Link 
metric types (including the first) are ordered as indicated in the 
Value field of an MPR_TYPES Message TLV. 


Homo HO O = + 
| Type | Value | 
+--------- +------------------- - - - O - = + 
GATEWAY Number of hops to attached network for each link metric 
type 
+--------- PO O = + 


Table 1: GATEWAY TLV Definition 
HELLO Messages 


The following changes are made to the generation and processing of 
HELLO messages compared to the description in [RFC7181] for routers 
that implement MI-OLSRv2. 


HELLO Message Generation 


A generated HELLO message to be sent on an OLSRv2 interface (whose 
IFACE_METRIC_TYPES parameter will be that used) is extended by: 


o Adding an MPR_TYPES Message TLV. The Value octets will be the 
link metric types in IFACE_METRIC_TYPES. This TLV MAY be omitted 
if the only link metric type included would be LINK_METRIC_TYPE. 


o Extending the MPR_WILLING Message TLV Value field to report the 
willingness values from the WILL_ROUTING parameter list that 
correspond to the link metric types in IFACE_METRIC_LIST, in the 
same order as reported in the MPR_TYPES TLV, each value (also 
including one representing WILL_FLOODING) occupying 4 bits. 


o Including LINK_METRIC Address Block TLVs that report all values in 
L_in_metric, L_out_metric, N_in_metric, and N_out_metric elements 
that are not equal to UNKNOWN_METRIC, with the TLV Type Extension 
being the link metric type, and otherwise following the rules for 
such inclusions specified in [RFC7181]. 


o Including MPR Address Block TLVs such that for each link metric 
type in IFACE_METRIC_TYPES, and for the choice of flooding MPRs, 
the indicated addresses MUST be of the MPRs in an MPR set as 
specified for a single link metric type in [RFC7181]. 
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HELLO Message Processing 


On receipt of a HELLO message on an OLSRv2 interface, a router 
implementing MT-OLSRv2 MUST do the following, in addition to the 
processing described in [RFC7181]: 


Te; 


If in this deployment there might be routers that do not 
implement MT-OLSRv2, the HELLO message contains an MPR_TYPES 
Message TLV, and the first link metric type that it reports is 
not LINK_METRIC_TYPE, then the HELLO message MUST be silently 
discarded. 


Determine the list of link metric types supported by the sending 
router on its corresponding OLSRv2 interface, either from an 
MPR_TYPES Message TLV (if present) or from the single link metric 
type LINK_METRIC_TYPE. 


For all link metric types reported and supported by the receiving 
router, set the appropriate L_out_metric, N_in_metric, 
N_out_metric, N_will_routing, N_mpr_selector, N_advertised, 
N2_in_metric, and N2_out_metric elements using the rules for 
setting the single elements of those types specified in 
[RFC7181]. 


For any other metric types supported by the receiving router only 
(i.e. in IFACE_METRIC for the receiving OLSRv2 interface), set 
the elements listed in the previous point to their default 
values, i.e., UNKNOWN_METRIC, WILL_NEVER (not WILL_DEFAULT), or 
false. 


TC Messages 


The following changes are made to the generation and processing of TC 
messages compared to that described in [RFC7181] by routers that 
implement MT-OLSRv2. 


Hs 


TC Message Generation 


A generated TC message is extended by: 


o 


Adding an MPR_TYPES TLV. The Value octets will be the link metric 
types in ROUTER_METRIC_TYPES. This TLV MAY be omitted if the only 
link metric type included would be LINK_METRIC_TYPE. 


Including LINK_METRIC TLVs that report all values of N_out_metric 
that are not equal to UNKNOWN_METRIC, with the TLV Type Extension 
being the link metric type, and otherwise following the rules for 
such inclusions specified in [RFC7181]. 
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o Including a number of hops per reported (in an MPR_TYPES Message 
TLV) link metric type in the Value field of each GATEWAY TLV 
included, in the same order as reported in the MPR_TYPES TLV. 


TC Message Processing 


On receipt of a TC message, a router implementing this extension MUST 
do the following, in addition to the processing specified in 
[RFC7181]: 


o If in this deployment there might be routers that do not implement 
MT-OLSRv2, the TC message contains an MPR_TYPES Message TLV, and 
the first link metric type that it reports is not 
LINK_METRIC_TYPE, then the TC message MUST be silently discarded. 


o For all link metric types reported and supported by the receiving 
router, set the appropriate TR_metric, TA_metric, AN_dist, and 
AN_metric elements using the rules for setting the single elements 
of those types specified in [RFC7181]. 


o For any other metric types supported by the receiving router that 
do not have an advertised outgoing neighbor metric of that type, 
set the corresponding elements of TR_metric, TA_metric, and 
AN_metric to UNKNOWN_METRIC. (The corresponding element of 
AN_dist may be set to any value.) 


MPR Calculation 


Routing MPRs are calculated for each link metric type in 
ROUTER_METRIC_TYPES. Links to symmetric 1-hop neighbors via OLSRv2 
interfaces that do not support that link metric type are not 
considered. The determined status (routing MPR or not routing MPR) 
for each link metric type is recorded in the relevant element of 
N_routing_mpr. 


Each router may make its own decision as to whether or not to use a 
link metric, or link metrics, for flooding MPR calculation. If using 
link metric(s), each router decides which one(s) and how they are 
used. These decisions MUST be made in a manner that ensures that 
flooded messages will reach the same symmetric 2-hop neighbors as 
would be the case for a router not supporting MT-OLSRv2. 


Note that it is possible that a 2-Hop Tuple in the Information Base 
for a given OLSRv2 interface does not support any of the link metric 
types that are in the router’s corresponding IFACE_METRIC_TYPES; 
nevertheless, that 2-Hop Tuple MUST be considered when determining 
flooding MPRs. 
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T2; 


Routing Set Calculation 


A Routing Set is calculated for each link metric type in 
ROUTER_METRIC_TYPES. The calculation may be as for [RFC7181], except 
that where an element is now represented by a map, the value from the 
map for the selected link metric type is used. Where this is a link 
metric of value UNKNOWN_METRIC, that protocol Tuple is ignored for 
the calculation. 


Management Considerations 


MT-OLSRv2 may require greater management than unextended OLSRv2. In 
particular, a MANET using MT-OLSRv2 requires the following management 
considerations: 


o Deciding which link metric, and hence which Routing Set to use, 
for received packets, hence how to use the Routing Sets to 
configure the network layer (IP). All routers MUST make the same 
decision for the same packet. An obvious approach is to map each 
DSCP [RFC2474] to a single link metric. (This may be a many-to- 
one mapping.) 


o Selecting which link metrics to support on each OLSRv2 interface 
and implementing that decision. (Different interfaces may have 
different physical and data link-layer properties, and this may 
inform the selection of link metrics to support, and their 
values.) If the MANET might contain non-MT-OLSRv2 routers, which 
are also subject to management, then the rules in this 
specification for link metric assignment to OLSRv2 interfaces for 
that case MUST be followed. 


o Ensuring that the MANET is sufficiently connected, by ensuring 
that, for example, sufficiently many routers implement each metric 
type required. (This is easier in, for example, a denser network.) 
Note that if there is any possibility that there are routers not 
implementing MT-OLSRv2, then the MANET will be connected, to the 
maximum extent possible, using the link metric type 
LINK_METRIC_TYPE, but this will only serve to deliver packets that 
use that link metric type. 


o Non-MT-OLSRv2 routers SHOULD be managed so as not produce packets 
that will be routed by a topology that they are not part of. 
However, if that were to happen, then such packets will be routed 
until either they reach their destination or they reach an 
MT-OLSRv2 router. In the latter case, the packet then either will 
be dropped (if that MT-OLSRv2 router is not part of that topology, 
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13 


or is not aware of the destination within that topology) or will 
be routed by that topology to the destination. Such a packet will 
not loop. 


o If a packet is created for a destination that is not part of the 
corresponding topology, then it may or may not be delivered (if 
the originating router is a non-MT-OLSRv2 router) or will not be 
sent (if the originating router is an MT-OLSRv2 router). Routers 
SHOULD be managed so that topologies are as complete as possible 
and that packets are not sent if they may not be delivered. In 
particular, non-MT-OLSRv2 routers SHOULD only send packets that 
will be routed using the topology using the link metric type 
LINK_METRIC_TYPE. 


IANA Considerations 


This specification adds one new Message TLV, allocated as a new Type 
Extension to an existing Message TLV, using a new name. It also 
modifies the Value field of an existing Message TLV and that of an 
existing Address Block TLV. Finally, this specification makes 
additional allocations from the LINK_METRIC Address Block TLV Type 
registry. 


1. Expert Review: Evaluation Guidelines 


For the registry where an Expert Review is required, the designated 
expert SHOULD take the same general recommendations into 
consideration as are specified by [RFC5444] and [RFC7631]. 


.2. Message TLV Types 


This specification modifies the Message TLV Type 7, replacing Table 4 
of [RFC7631] by Table 2, changing the description of the Type 
Extension MPR_WILLING, and adding the Type Extension TLV_TYPES. Each 
of these TLVs MUST NOT be included more than once in a Message TLV 
Block. 
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2-223 
224-255 


Table 2: 
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MPR_WILLING 


MPR_TYPES 


Mult 


+ 
| 
| 

=---+ 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 

+ 


i-Topology OLSRv2 


First (most 
significant) half-octet 
of Value field 
specifies the 
originating router's 
willingness to act as a 
flooding MPR; 
subsequent half-octets 
specify the originating 
router's willingness to 
act as a routing MPR, 
either for the link 
metric types reported 
in an MPR_TYPES TLV (in 
the same order), or (if 
no MPR_TYPES TLV is 
present) for the single 
administratively agreed 
link metric type 

The link metric types 
supported on this 
OLSRv2 interface of 
this router (one octet 
each). 

Unassigned 

Reserved for 
Experimental Use 


+ 
| 
| 

+ 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 

+ 
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Type 7 Message TLV Type Extensions 


Experimental 


[Page 19] 


REC 7722 


Multi-Topology OLSRv2 December 2015 


13.3. Address Block TLV Types 


Table 7 of [RFC7188] 


is replaced by Table 3. 


doo doo do $ O O + 
| Bit | Value | Name | Description 
doo doo do $ O O O O O + 
| First | First | Flooding | If set, then the neighbor with that | 
octet octet | network address has been selected as | 
| Þit-7 | 0x01 | flooding MPR 
| From | From | Routing | If set, then the neighbor with that | 
| first | first | | network address has been selected as | 
| octet | octet | | routing MPR, either for the link | 
| bit 6 | 0x02 | | metric types reported in an MPR_TYPES | 
| | | | TLV (in the same order), or (if no | 
MPR_TYPES TLV is present) then (first | 
| | | octet bit 6, value 0x02) for the 
| | | | single administratively agreed link | 
| | | | metric type | 
doo doo do SS pas SS SS SS SS SS a + 
Table 3: MPR TLV Bit Values 
Table 14 of [RFC7631] is replaced by Table 4. The only changes are 
to the Description and the References for the GATEWAY TLV. 
feos Sn 2 Fosas soe He OS iento SS + 
Type Name Description References 
Extension 
4+----------- do $ T E +--------------- + 
| 0 | GATEWAY | Specifies that a given | [RFC7181] 
| | | network address is reached | RFC 7722 | 
| | | via a gateway on the | 
originating router. The | 
| | | number of hops is indicated 
| | | by the Value field, one | 
| | | octet per link metric type | 
| | | reported in an MPR_TYPES | | 
| | | Message TLV (in the same | 
order) or (if no MPR_TYPES | | 
| | Message TLV is present) 
| | | using a single octet | 
| 1-223 | | Unassigned | 
| 224-255 | | Reserved for Experimental | [RFC7631] 
| | | Use | | 
do do $ O O $2 ann + 
Table 4: Type 10 Address Block TLV Type Extensions 
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Table 13 of [RFC7181] is replaced by Table 5. 


December 2015 


The only change is 


that 8 Type Extensions are allocated as assigned by administrative 
action, in order to support administratively determined multi- 


topologies. 
+------------- +------ +----------- +------------------- 
| Name | Type | Type | Description 
| | | Extension | 
+------------- +------ +----------- +------------------- 
| LINK_METRIC | A 0-7 | Link metric 
| | | | meaning assigned 
| | | | by administrative 
| | | | action. 
| LINK_METRIC | 7 | 8-223 | Unassigned. 
| | | | 

LINK_METRIC 7 224-255 Unassigned. 
+------------- +------ +----------- +------------------- 


Table 5: Address Block TLV Type assignment: 


14. Security Considerations 


——— + —— + 


+ 


A A Ts a ql je en el te ee + 
Allocation | 
Policy | 

E he te ee + 

| 
| 
| 
| 
Expert | 
Review | 
Experimental 
Use 
SS Ss + 


LINK_METRIC 


This extension to OLSRv2 allows a router to support more than one 
link metric type for each link advertised in HELLO and TC messages, 


and for routers to support 


different sets of types. 


L 


ink metric 


values of additional types are reported by the inclusion of 


additional TLVs in the messages sent by a router, 


known values of all supported types. 


which will report 


HELLO and TC message processing is then extended simply to record, 
for each supported type, all of the received link metric values for 


each link. Protocol-internal processing 


shortest path calculations) 


Consequently, the security 


architecture and the mandatory security mechanisms, 


are directly applicable to 


(specifically, MPR set and 


then operates as specified in [RFC7181] 
for each link metric type that the router supports. 


considerations, including the security 


MT-OLSRv2. 


from [RFC7181] 


Furthermore, this extension does not introduce any additional 


vulnerabilities beyond those of [RFC7181], 


type is used independently, 


receiving the same information, 


because each link metric 


and each one could have been the single 
link metric type supported by an implementation of [RFC7181] 


unsupported type is ignored by all routers. 
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